exploit di caratteri multibyte - PHP / MySQL

19

Qualcuno potrebbe indicarmi un collegamento con alcune informazioni sugli exploit di caratteri multibyte per MySQL? Un amico li ha portati alla mia attenzione, ma non sono riuscito a trovare molte informazioni su Internet.

    
posta bstpierre 20.12.2011 - 07:08
fonte

2 risposte

20

Riepilogo. Sì, il problema è che, in alcune codifiche di caratteri (come UTF-8), un singolo carattere è rappresentato come più byte. Un modo in cui alcuni programmatori tentano di impedire a SQL injection di sfuggire a tutte le virgolette singole in input non attendibili, prima di inserirle nella loro query SQL. Tuttavia, molte funzioni standard di escape delle virgolette ignorano la codifica dei caratteri che il database utilizzerà ed elaborerà il loro input come una sequenza di byte, ignaro del fatto che un singolo carattere potrebbe riempire diversi byte. Ciò significa che la funzione di evasione delle quotazioni sta interpretando la stringa in modo diverso rispetto al database. Di conseguenza, vi sono alcuni casi in cui la funzione di evasione delle quotazioni potrebbe non riuscire a scappare porzioni della stringa che il database interpreterà come codifica multi-byte di una singola citazione; o potrebbe inavvertitamente spezzare una codifica di caratteri multibyte in un modo che introduce una citazione singola in cui non era presente in precedenza. Pertanto, gli exploit di caratteri multi-byte offrono agli aggressori un modo per fare attacchi di tipo SQL injection anche quando il programmatore pensava di fuggire adeguatamente dai loro input al database.

L'impatto. Se utilizzi istruzioni preparate / parametrizzate per formare tutte le connessioni del database, sei al sicuro. Gli attacchi multi-byte falliranno. (Escludendo bug nel database e nella libreria, ovviamente. Ma empiricamente, quelli sembrano essere rari.)

Tuttavia, se provi a sfuggire a input non attendibili e quindi a creare una query SQL in modo dinamico utilizzando la concatenazione di stringhe, potresti essere vulnerabile agli attacchi multibyte. Che tu sia effettivamente vulnerabile dipende da dettagli specifici della funzione di escape che usi, dal database che utilizzi, dalla codifica dei caratteri che stai utilizzando con il database e, possibilmente, da altri fattori. Può essere difficile prevedere se gli attacchi multi-byte avranno successo. Di conseguenza, la creazione di query SQL utilizzando la concatenazione di stringhe è fragile e non consigliata.

Dettagli tecnici. Se desideri leggere i dettagli degli attacchi, posso fornirti una serie di link che spiegano gli attacchi in modo dettagliato. Esistono diversi attacchi:

  • Attacchi di base su, ad esempio, UTF-8 e altre codifiche di carattere mangiando barre / barre rovesciate aggiuntive introdotte dalla funzione di quotatura: vedere, ad esempio, qui .

  • Attacchi subdoli, ad esempio, GBK, che funzionano ingannando la funzione di quotatura per introdurre una citazione extra per te: vedi, ad esempio, blog di Chris Shiflett , qui o qui .

  • Attacca, ad esempio, UTF-8, che nasconde la presenza di una citazione utilizzando una codifica non canonica non valida (più lunga) della virgoletta singola: vedi, ad esempio, qui . Fondamentalmente, il modo normale di codificare una virgoletta singola lo inserisce in una sequenza a byte singolo (vale a dire, 0x27 ). Tuttavia, esistono anche sequenze multi-byte che il database potrebbe decodificare come una virgoletta singola e che non contengono il byte 0x27 o qualsiasi altro valore di byte sospetto. Di conseguenza, le funzioni standard di escape delle virgolette potrebbero non riuscire a sfuggire tali citazioni.

risposta data 20.12.2011 - 10:00
fonte
5

Gli attacchi a più byte non sono limitati a SQL Injection. In generale, gli attacchi multi-byte portano a una condizione di "consumo in byte" in cui l'attaccante sta rimuovendo i caratteri di controllo. Questo è l'opposto del classico ' or 1=1-- , in cui l'attaccante sta introducendo il carattere di controllo a virgolette singole. Per mysql c'è mysql_real_escape_string() che è progettato per occuparsi dei problemi di codifica dei caratteri. Le librerie di query parametrizzate come PDO utilizzeranno automaticamente questa funzione. MySQLi invia effettivamente i parametri della query come elemento separato all'interno di una struttura, evitando completamente il problema.

Se una pagina HTML viene renderizzata tramite Shift-JIS, è possibile utilizzare i caratteri di controllo per ottenere XSS. Un eccellente esempio di questo è stato fornito in " A Tangled Web " (libro fantastico!) A pagina 207:

<img src="http://fuzzybunnies.com/[0xE0]">...thisisstillapartofthemkarup......butthesreverdosn'tknow..." onload="alert('this will execute!')"
<div>
...page content continues...
</div>

In questo caso 0xE0 è un byte speciale che indica l'inizio di un simbolo a 3 byte. Quando il browser esegue il rendering di questo codice HTML, il flusso percentuale di"> verrà consumato e trasformato in un singolo simbolo Shift-JIS. Se l'attaccante controlla il seguente input per mezzo di un'altra variabile, può introdurre un gestore di eventi per ottenere l'esecuzione del codice.

    
risposta data 03.01.2012 - 18:03
fonte

Leggi altre domande sui tag